Reflection Scan: an Off-Path Attack on TCP 



Jan Wrobel 

wrr@mixedbit . org 



Abstract 

The paper demonstrates how traffic load of a shared 
packet queue can be exploited as a side channel through 
which protected information leaks to an off -path attacker. 
The attacker sends to a victim a sequence of identical 
spoofed segments. The victim responds to each segment 
in the sequence (the sequence is reflected by the victim) 
if the segments satisfy a certain condition tested by the 
attacker. The responses do not reach the attacker directly, 
but induce extra load on a routing queue shared between 
the victim and the attacker. Increased processing time of 
packets traversing the queue reveal that the tested con- 
dition was true. The paper concentrates on the TCP, but 
the approach is generic and can be effective against other 
protocols that allow to construct requests which are con- 
ditionally answered by the victim. A proof of concept 
was created to assess applicability of the method in real- 
life scenarios. 

1 Introduction 

The TCP protocol without an additional encryption and 
authentication layer is inherently vulnerable to man-in- 
the-middle attacks. An attacker that has a way to inter- 
cept network traffic between TCP end points, can easily 
read and alter the communication. Off-path attacks, in 
which the attacker can not intercept network traffic, are 
much harder to execute. Along the years several weak- 
nesses in the protocol or particular implementations that 
made off-path attacks easier were disclosed. Protocol 
specification was improved and many vendors fixed im- 
plementations to close discovered holes. A TCP con- 
nection between hosts that implement the newest recom- 
mendations ([3], [4], [5]) is believed to be reasonably 
well protected against off-path attacks. 

A TCP session is protected by three secret numbers: 
a 16-bit ephemeral port and two 32-bit sequence num- 
bers, one for each side of the connection. Other fields, 



such as IP addresses of end points and a server port, are 
easy to determine in many scenarios. Each TCP seg- 
ment exchanged within an established connection carries 
all three secret values. For a segment to be accepted, 
it must contain a correct ephemeral port number, its se- 
quence number must be within receiver's window and 
a sequence number the segment is acknowledging (ac- 
knowledge number) must be acceptable. According to 
the recent recommendations, an ephemeral port should 
be randomly picked from a 1025-65535 range and an ac- 
knowledge number should be accepted only if it is equal 
to the next octet to be sent or lower by at most 'largest 
sender window seen' . If an end point follows these rec- 
ommendations, the attacker needs 

(2 16 - 1025) x 2 32 x 2 32 
window size A x window size B 

attempts to generate an acceptable segment. Assuming 
both windows have 65kB, about 2 48 attempts are needed. 
If the end point follows strict RST validation rules, which 
require RST segment to have a sequence number equal to 
the next expected sequence number, the attacker needs 
(2 16 — 1025) x 2 32 attempts to blindly reset the connec- 
tion, which is also about 2 48 . The number is large enough 
to make blind attacks impractical in most scenarios. The 
attacker would need to push segments for 500 hours at 
lOOGb/s rate to have one segment accepted. Even if a 
segment is accepted, the probability that it lines up with 
a start of a window is only ^gxjL size ■ Thus, a success- 
ful blind attack can corrupt or reset the session, but it 
has low chances of inserting a meaningful payload in a 
correct place. 

While the risk of accepting spoofed TCP segments as 
valid is recognized and well studied, the recommenda- 
tions and implementations overlook the risk of respond- 
ing to rejected segments. A TCP layer can either silently 
drop a rejected segment or respond to it (with an ACK or 
a RST). The action to perform differs between different 
implementations of the protocol. It was originally spec- 
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ified in the 'Event Processing' section of RFC 793 [1], 
but new systems, especially firewalls, do not fully fol- 
low the RFC, but implement stricter filtering rules, as for 
example described in [2]. These new rules are carefully 
specified to preserve interoperability between different 
implementations. 

If for a particular TCP implementation conditional re- 
sponse to a rejected segment depends on one of secret 
values set in the segment, and if an attacker can discover 
that a system responded to a spoofed segment, the TCP 
session can be compromised. The attacker can determine 
if a tested secret value satisfied certain condition (an 
ephemeral port was correct, a sequence number was in 
window, an acknowledge number was acceptable). The 
secrets can be revealed in separate steps, each of the steps 
requires relatively small resources. 

Congestion of a queue shared between the off-path 
attacker and the targeted TCP stream is a side channel 
through which the attacker can determine if the TCP 
layer responded to spoofed segments. Detecting negli- 
gible load caused by a single response would be hard 
in practice, but the attacker can send a sequence of seg- 
ments of any desired length. If each segment from the se- 
quence is answered, the answers can cause a substantial 
traffic spike or even queue overflow. Figure 1 illustrates 
the technique. 

2 Related work 

A high correlation between traffic patterns of users shar- 
ing a routing resource was demonstrated in [6]. The au- 
thors monitored ping round trip time to a router that con- 
nected a user to the Internet and compared the measure- 
ments with traffic patterns generated by the user's online 
activities. In this technique the eavesdropper was passive 
and did not send any packets to trigger traffic spikes and 
gain additional information. 

The attack described in this paper shares a lot of simi- 
larities with well known off -path techniques that exploit 
weak implementations of IP ID generation mechanism. 
Some legacy systems increase the ID field of subsequent 
IP packets that leave a machine by one. This provides a 
side channel to determine if a host sent a packet in re- 
sponse to incoming traffic. The channel can be used to 
perform stealth port scans [7] or to execute off-path at- 
tacks against established TCP connections [8]. Contrary 
to the technique described in this paper, the exploitation 
of IP ID channel requires an attacker to establish a legit- 
imate, bidirectional communication channel to a vulner- 
able host. Today firewalls commonly disallow creation 
of such channels to client machines. This document con- 
centrates on compromising TCP session, but the tech- 
nique can also be used to perform a stealth port scan 
analogous to the one described in [7]. 
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Figure 1 : High level attack scheme. The attacker sends 
a query to the victim in a form of a sequence of spoofed 
segments. If the answer to the query is positive, the vic- 
tim responds with a sequence of segments addressed to 
its peer. At the same time, the attacker sends ping probes 
that share an outbound queue with segments from the 
victim. Increased round trip time reveals the positive an- 
swer to the query. 



The authors of [9] showed that TCP congestion con- 
trol mechanism can be exploited by a malicious receiver 
to improve performance of his/her connection at the cost 
of others. Applicability of such technique for a Denial of 
Service attack was studied in [10]. In simulated environ- 
ment the authors were able to significantly decrease the 
bandwidth of participating TCP connections. Security 
Assessment of the TCP [5] explains that such attacks can 
be executed blindly by an off -path attacker. Congestion 
control mechanism is driven by ACK segments and TCP 
layer can be easily tricked to generate ACKs by spoofed 
segments with incorrect sequence numbers. 

3 Requirements and applicability 

As in case of most off -path attacks, the attacker must be 
able to send spoofed IP packets to one end of the tar- 
geted connection. It is also assumed that IP addresses 



2 



of both ends and a port number of a server are known 
to the attacker. Throughout the paper, the end point to 
which spoofed segments are addressed is called 'the vic- 
tim', the second end point is called 'the victim's peer'. 

In addition to these usual requirements, the attacker 
must be able to send legitimate traffic probes through (or 
to) one of the machines (a router or an end point) on the 
path of the targeted TCP traffic. Ideally, the machine 
should be a bottleneck for the TCP connection. As de- 
scribed in [6], a good candidate is an edge router con- 
necting the victim to the Internet. The probes can be 
ICMP pings, but also segments exchanged within a le- 
gitimate TCP connection, anything that would allow to 
detect changes in traffic load of the bottleneck. 

There are various factors that influence applicability 
of the attack: 

• Available bandwidth and time. The bigger the band- 
width between the attacker and the victim the better. 
The smaller the bandwidth between the victim and 
its peer the better. 

• Bottleneck's natural traffic patterns. The attack is 
harder if the traffic traversing the bottleneck is large 
or has variable characteristic. 

• Network topology. The attack is easier if spoofed 
segments from the attacker to the victim do not tra- 
verse the bottleneck, and thus do not disturb traffic 
probes sent by the attacker. 

• Bottleneck's queuing policy. Good isolation of traf- 
fic coming from different users can impede the at- 
tack. 

• Traffic measuring and analyzing technique. Ad- 
vanced techniques can increase the attack feasibility 
in adverse scenarios. 

It is beyond the scope of this paper to determine the 
practical limits of the technique. The results of per- 
formed experiments can provide a reference point for 
analyzing applicability of the attack in different scenar- 
ios. The proof of concept can be used a starting point 
for further experiments. The attack requires much fewer 
resources than truly blind off -path attack, but the require- 
ments are still significant enough to make it impractical 
in many real-life scenarios. 

4 Experimental setup 

The experiments were performed in favorable for the at- 
tacker, but not improbable conditions. The attacker was 
sharing an edge router with the victim. The router had 
2500kb/s downlink and 320kb/s uplink connection to the 
Internet. The attacker was connected to the victim with 



lOOMb/s link, but did not have direct access to the vic- 
tim's traffic. Three different scenarios were considered: 

• Idle TCP connection with negligible natural traffic 
traversing the bottleneck. This scenario was the eas- 
iest one, induced responses constituted substantial 
part of bottleneck's traffic. 

• The victim downloading data at full speed (satu- 
rated downlink). 

• The victim uploading data at full speed (saturated 
uplink). 

The attacker sent ping requests to a router one hop be- 
yond the edge router. This ensured ping packets and seg- 
ments sent by the victim in response to spoofed traffic 
shared an outgoing queue of the edge router. When the 
link to the outside world was idle, the ping Round Trip 
Time was about 20ms, when the link was saturated, the 
RTT increased to about 700ms. 

Two systems were analyzed. Windows XP SP3 with 
firewall enabled and Linux 3.0.0. Linux had Netfilter 
firewall enabled with following commands: 

iptables -A INPUT -m state \ 

—state ESTABLISHED -j ACCEPT; 
iptables -A INPUT -j DROP; 

This is a common configuration for a client machine. All 
incoming traffic that it not directed to connections initi- 
ated by the protected machine is dropped. 

The two tested systems implement different rules for 
processing TCP segments. To determine how a host pro- 
tected by a firewall responds to an incoming segment two 
steps need to be analyzed: is firewall going to drop the 
segment and if not, how TCP layer is going to handle the 
segment? The differences between the two tested sys- 
tems come from the first step - Netfilter imposes stricter 
filtering rules ([2]) than Windows XP firewall. The sec- 
ond step for both systems is the same (in respect to pro- 
cessing rules exploited by the attack) and closely follows 
RFC 793. Processing rules that are important from the 
attack perspective are briefly explained in following sec- 
tions. 

The proof of concept that was used to obtain experi- 
mental results can be found at [16]. The paper does not 
discuss low level details of the implementation, an in- 
terested reader is encouraged to study a documentation 
accompanying the code. 

It is important to note that no bugs in TCP implemen- 
tations of targeted systems were exploited. 

5 Attack details 

Assuming a shared router implements FIFO queuing pol- 
icy, delay introduced by a series of N packets of equal 
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size is: 



N * packet size 



bandwith 

The victim is tricked to generate ACK segments, which 
have about 80 bytes (assuming about 40B for layer two 
header, 20B for IP and about 20B for TCP headers). Ap- 
plying the formula to the experimental setup, a theoret- 
ical delay introduced by 30 ACK segments should be 
s = 0.06s. It is three times more than the ping 



30*80*8 
320000 



RTT for the idle link (20ms), and should be easily de- 
tectable in the easiest experimental scenario. 1000 ACKs 



should introduce a delay of 



1000*80*8 
320000 



s = 2.0s. This is 



about three times more than the ping RTT for the satu- 
rated link (700ms), and should be easily detectable in the 
download and upload experiments. 

5.1 Ephemeral port number 

'Event Processing' section of RFC 793 requires an ACK 
segment to be sent in response to any segment that be- 
longs to an established connection (has correct IP ad- 
dresses and ports) but is outside of a window (has an in- 
correct sequence number). If a host adheres to this spec- 
ification, and is protected by a firewall that silently drops 
segments not belonging to any connection (a common 
case), the attacker can use segments with an incorrect se- 
quence number to determine a client port number. 

Windows and Linux TCP stacks follow the RFC and 
respond with ACK to any segment with an incorrect se- 
quence number. Linux Netfilter firewall uses stricter val- 
idation rules to drop segments that are not part of a con- 
nection: 

• Segments without ACK flag are dropped. 

• Acknowledge number is validated. It is 
accepted only if it is equal to the next 
octet to be sent or lower by at most 
max(66000, largest sender window seen). 

Acknowledge number validation makes it much harder 
to use segments with an incorrect sequence number to 
search for a client port. But there is a hole: 

• Segments that have both SYN and ACK flag set are 
always accepted and passed to the TCP layer. 

TCP layer responds with ACK to such segments if 
their sequence number is outside of a window. This al- 
lows to discover an ephemeral port of a Netfilter pro- 
tected host. The only drawback is that if a sequence num- 
ber of SYN-ACK segment accidentally happens to be in- 
window, Linux responds with RST and the connection is 
closed. The probability of this is low: wind 2 ( g size . 

Figure 2 shows how ping RTT increases when a se- 
quence of spoofed segments is directed at the correct 



ephemeral port. A spike in RTT occurs reliably, but usu- 
ally it is not the only detected spike. Proof of concept 
code repeated all queries for which a spike was detected 
until a single query was left. This allowed to reveal an 
ephemeral port with a high success rate. 
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Figure 2: The change in pings' loss rate reveal an 
ephemeral port in use (11235). Ping is considered lost 
if the response did not arrive within two RTTs of previ- 
ous pings related to the same port. 

The lower bound on a query time is a single ping 
RTT, because at least one ping needs to be sent to de- 
termine the query result. Even for a relatively short RTT 
of 20ms, if a full range of 64k ephemeral ports needs 
to be scanned, the sequential scan would require at least 
21 minutes. When bandwidth from the attacker to the 
victim is large, continuous range of ports can be probed 
in each sequence of spoofed segments. Such sequence 
can be interpreted as a query 'Is the connection using a 
port between X and Y?' . If a part of the sequence is re- 
flected, the answer is yes, and a sequential search can be 
used to find the exact port number. In the experimental 
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setup such range queries worked well and considerably 
reduced time of the scan (see figure 3). Table 1 summa- 
rizes experimental results. The results were similar for 
both tested systems. The attacker can further improve 
performance if the targeted connection uses ephemeral 
port from a smaller range. 
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Figure 3: The range scan of an idle connection. Spoofed 
segments are covering 200 port ranges. 5 pings and 6000 
spoofed segments (30 to each port) are sent for each 
range. RTT and loss rate spikes reveal the ephemeral 
port is somewhere between 1 1200 and 1 1400. 



A side note on Netfllter 

It is interesting why Netfilter does not drop SYN-ACK 
segments arriving in a context of an already established 
connection. There are at least two signals that indicate a 
SYN-ACK segment is incorrect: 1 . ACK number does 
not acknowledge any SYN segment, 2. Data was already 
exchanged in both directions, three way handshake must 
have had finished successfully. A comment in the Net- 
filter source code says 'Our connection entry may be out 
of sync, so ignore packets which may signal the real con- 
nection between the client and the server' (ignore here 
means do not drop). The problem is that Netfilter is a 
completely separate layer from the Linux TCP stack. It 
does not have access to the real state of a TCP connec- 
tion, but recreates it based on segments it has seen. It 
does not assume the protected end point is on the same 
machine and that segments it has accepted reached the 
destination. For these reasons, tracking state of a TCP 
connection and determining if a segment can be safely 
dropped is very complex. As demonstrated in [2], there 
are many corner cases to consider that can lead to hanged 
connections when handled incorrectly. 



5.2 Sequence numbers 

To inject data at the start of a window of a one end of the 
connection (the victim or its peer), the attacker needs to 
know the sequence number of the next octet to be sent 
(SND.NXT) by the other end. The exact value of the 
SND.NXT of the end point to which data is inserted does 
not need to be known, it is enough that the segment that 
injects data has an acceptable acknowledge number set. 
Injecting data is relatively easy if the end point is not ac- 
tively receiving data from its peer. If it is not the case, 
the window and SND.NXT constantly change, introduc- 
ing an additional obstacle that the attacker needs to over- 
come. The paper does not try to address these difficulties. 

Steps needed to determine SND.NXTs significantly 
differ for the two tested systems. In both cases ACK 
segments with an ephemeral port determined in the pre- 
vious step are used. Windows firewall never drops ACK 
segments that are exchanged withing an established con- 
nection (have correct IP addresses and ports), so only 
rules defined in RFC 793 need to be taken into account 
when analyzing Windows responses. Netfilter imple- 
ments stricter filtering rules. The following subsections 
demonstrate that stricter filtering can significantly reduce 
resources needed by the attack. 

Host strictly following RFC 793 

The sequence number of the victim's peer needs to be 
determined first. If a sequence number of an incoming 
ACK segment is in window, and an acknowledge number 
is acceptable, the segment does not trigger any response. 
Otherwise, ACK segment is sent in response. Accord- 
ing to RFC 793, acknowledge number is acceptable if it 
is equal to the next octet to be sent or lower by at most 
2 31 . In other words, an acceptable acknowledge number 
lies in range: [SND.NXT - 2 31 , SND.NXT] (using the 
'sequence space arithmetic'). Because of this, out of two 
acknowledge numbers that differ by 2 31 one is guaran- 
teed to be acceptable. The attacker needs to send 



N- 



2x2 32 
window size 



queries to find in-window sequence number. The risk 
of accidentally corrupting the session is negligible. The 
session would be corrupted only if the attacker happens 
to acknowledge data that was lost in transit. In such case 
the data won't be retransmitted. 

The attacker does not need to know the size of the vic- 
tim's window, although it can be often easily determined 
(see [11]). The attacker can first assume the maximum 
allowed window (1GB) and try sequence numbers that 
differ by 2 30 . If none of such sequence numbers is in- 
window, the attacker can try sequence numbers in the 
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Table 1 : Ephemeral port search. The full space of 65k ephemeral ports was searched. 



connection 
type 


scan 
time[s] 


queries 


pings 


max ports 
per query 


spoofed 
segments 


reflected 
segments 


idle 


35 


592 


2960 
5/query 
0.25MB total 
22ms avg RTT 


200 


2202780 
30/port/query 
171MB total 


330 
25kB 


download 


852 


849 


8490 
10/query 
0.7MB total 
749ms avg RTT 


100 


73614000 
1000/port/query 
5741MB total 


12000 
0.9MB 


upload 


690 


852 


8520 
10/query 
0.7MB total 
656ms avg RTT 


100 


74013000 
1000/port/query 
5773MB total 


10000 
0.8MB 



middle of ranges probed in the previous step. If the vic- 
tim uses 0.5GB window, one of such sequence numbers 
should be in-window. The steps can be repeated, each 
time the assumed window size is divided by two until 
in-window sequence number is found. Such search is 
described with more details in [8]. 

Out of N queries, a single one that does not generate 
a positive response needs to be found. The situation is 
opposite to the port scanning, where a single query that 
does generate a response was searched for. In practice, 
searching for a negative answer is more difficult: 

• Bottleneck is constantly overloaded. Scanning 
needs to be done in sequence, with long enough 
intervals between subsequent queries for a bottle- 
neck's queue to empty. Scanning several values at 
once is not possible - it is relatively easy to distin- 
guish between a traffic spike and a lack of traffic 
spike, it is much harder to distinguish between a 
traffic spike and a slightly smaller traffic spike. 

• Natural traffic may mask the lack of response. In 
contrast, when query to which the system responds 
is searched for, natural traffic can only magnify the 
traffic spike. 

Figure 4 illustrates how RTT decreases when a probed 
sequence number is within window. Table 2 shows that 
even in case of an idle connection, the time needed for 
a scan to finish is significant. In the experimental setup, 
the PoC code would need roughly about 36 hours to com- 
plete a sequential scan of a connection uploading data. 

Knowing in-window sequence number, the attacker 
can find the victim's peer SND.NXT by looking for the 
lowest sequence number that does not generate a re- 
sponse. Such value is at most window size before the 



in-window sequence number and can be found with bi- 
nary search in Zog(window size) queries. 

Also, if the value of the victim's SND.NXT is needed, 
it can be now easily determined. 3 1 queries are required 
to binary search for the highest acknowledge number 
that does not generate any response (is acceptable). This 
number is equal to the SND.NXT of the victim. 

Host protected by Netfllter 

The sequence number of the victim is determined first. 
The technique exploits acknowledge number valida- 
tion rules described in section 5.1. An ACK seg- 
ment is accepted only if its acknowledge number is 
equal to the next octet to be sent or lower by at 
most max(66000, largest sender window seen). In other 
words, an acceptable acknowledge number lies in range: 
[SND.NXT — max(66000, largest sender window seen), 
SND.NXT] (using the 'sequence space arithmetic'). A 
segment with not acceptable acknowledge number is 
silently dropped by the firewall. Netfllter does not val- 
idate sequence numbers of ACKs. Linux TCP layer to 
which not dropped segments are passed, validates a se- 
quence number and responds with ACK if it is out of a 
window. 

This allows to find an acceptable acknowledge number 
in 2 32 /max(66000, largest sender window seen) tries. If 
the victim responds to a segment that had an incor- 
rect sequence number, it means the acknowledge num- 
ber was accepted by Netfllter. Searching for an accept- 
able acknowledge number is analogous to searching for 
an ephemeral port. At most 2 32 /66000 = 65075 values 
need to be probed and only one of these values generates 
a positive response, which allows to probe several val- 
ues in a single query. See table 1 again for estimates of 
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Table 2: In-window sequence number search for the host strictly following RFC 793 processing rules. The host used 
a window of 65kB. 



connection 
type 


scan 
time[s] 


queries 


pings 


spoofed 
segments 


reflected 
segments 


idle 


16860 
~5h 


131338 


394014 
3/query 
32MB total 
85ms avg RTT 


3940140 
30/query 
307MB total 


3939930 
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Figure 4: When a sequence number of a spoofed seg- 
ment is in-window, the smallest average RTT and loss 
rate are measured. The RTT and loss rate of other probes 
are large, increasing duration of the scan. Natural traffic 
spike could mask a minimum. Ping is considered lost if 
the response did not arrive within two RTTs of previous 
pings related to the same sequence number. 



resources needed. 

There is a trick that allows to further improve the 
search efficiency. Netfilter can be easily fooled to set 
the value of the 'largest sender window seen' to the max- 
imum value allowed by a window scaling factor that was 
set during the connection establishment. To do it, 65075 
ACKs need to be sent, covering the whole 2 32 acknowl- 
edge number space with values that differ by 66000. 
All these ACKs need to have window size set to the 
maximum allowed value: OxFFFF. One of the ACKs 
should be accepted by Netfilter and sets maximum win- 
dow seen so far to OxFFFF x 2 window scalin § factor (note 
that this does not affect the real window size, the TCP 
end point rejects the ACK because it carries an incorrect 
sequence number). In the experimental setup, the sender 
set the window size to 1 14 with the scaling factor of 7, 
which resulted in a small window of 1 14 x 2 7 = 14592B. 
The sequence of spoofed ACKs fooled Netfilter that the 
window increased to OxFFFF x 2 7 = 8388480B. Such 
a window allowed to cover the whole 2 32 acknowledge 
number space with only 512 values. As it was the case 
when the host following RFC 793 was targeted, the at- 
tacker does not need to know the size of the victim's 
window and the scaling factor. Maximum allowed win- 
dow of 1GB can be assumed, and divided by two until an 
acceptable acknowledge number is found. 

See table 3 for summary of resources needed by the 
search. 

Knowing an acceptable acknowledge number, binary 
search can be used to find the sequence number of 
the next octet to be sent by the victim. This requires 
log (max (66000, largest sender window seen)) queries. 

If the victim's peer SND.NXT needs to be known, the 
attacker has several ways to reveal it: 

• Segments with a single byte of data can be used. 
Netfilter validates sequence numbers of segments 
that carry data. If the number is in-window, the seg- 
ment is passed to the TCP layer which generates 
ACK in response because data is out of order. If 
the sequence number is out of the window, Netfilter 
drops the segment. This technique carries the risk 
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Table 3: Acceptable acknowledge number search. The attacker fooled Netfilter that the sender window increased to 
8.3MB, this allowed to cover the whole acknowledge number space with a small number of queries. 



connection 
type 


scan 
time[s] 


queries 


pings 


max ack values 
per query 


spoofed 
segments 


reflected 
segments 


idle 


3.4 


60 


300 

5/query 
24kB total 
21ms avg RTT 


25 


20520 

30/ack value/query 
1.6MB total 


240 
18kB 


download 


61 


51 


510 

10/query 
42kB total 
866ms avg RTT 


25 


627000 

1000/ack value/query 
49MB total 


4000 
0.3MB 


upload 


59 


56 


560 

10/query 
45kB total 
602ms avg RTT 


25 


728000 

1000/ack value/query 
57MB total 


6000 
0.5MB 



of corrupting the session with the accepted byte. 

• If the attacker is able to send spoofed traffic to both 
ends, and to reliably monitor traffic spikes of both 
ends, the other end of the connection can be tar- 
geted. If the other end follows the RFC 793, only 
32 queries are needed to find the second SND.NXT. 
If it is protected by Netfilter, the steps described in 
this section can be used again. 

• Resource intensive search for a sequence number 
that does not generate any response can be per- 
formed in a similar way it was done for a sys- 
tem following RFC 793 in the previous subsection. 
The only difference is that acceptable acknowledge 
number is already known, only in-window sequence 
number needs to be found. 

5.3 Other variants 

Different TCP stacks may implement different segment 
processing rules, possibly closing some leaks described 
in this paper, or opening new ones. For example, to pre- 
vent a blind RST injection attack described in [12], a new 
recommendation for RST processing was created [3]. 
According to RFC 793 any in-window RST should be 
accepted and should reset the connection. The stricter 
and safer rules require RST to have sequence number ex- 
actly equal to the next expected sequence number, oth- 
erwise, in-window RST segment should generate ACK 
in response without resetting the connection. The docu- 
ment advises to optionally throttle such ACKs. If such 
ACKs are not throttled, the attacker can query for a win- 
dow using RST segments with little risk of accidentally 
resetting the connection. 



6 Advanced scanning technique 

TCP Fast Retransmit [13] can be exploited to trigger 
substantial traffic spikes with relatively small number 
of spoofed segments. Fast Retransmit is activated by 
3 duplicated ACKs. TCP layer interprets such dupli- 
cates as a message that a segment was lost but 3 sub- 
sequent segments successfully arrived at the destination. 
Each following duplicated ACK is interpreted as an ac- 
knowledgement that another segment was successfully 
received, but the lost segment still didn't reach the des- 
tination. Because segments are successfully leaving the 
network, sender sends a new segment in response to each 
such duplicated ACK. A burst of ACKs can trick the 
sender to send a full window of data in a very short time 
as described in [9]. The amplification factor for a net- 
work with MTU 1500 is 37. This allows the attacker to 
trigger observable traffic spikes with much fewer spoofed 
segments. 

The technique can also be used to detect ephemeral 
port number of a host that does not filter segments ad- 
dressed to not existing connection but responds with RST 
to each such segment. A sequence of spoofed segments 
directed to an incorrect port, results in a sequence of 
RSTs that are silently dropped by the other end point 
with no side effect. A sequence of spoofed segments di- 
rected to the correct port, results in a sequence of ACKs 
that trigger the other side to abruptly send a full win- 
dow of data. If the attacker can detect the spike in traffic 
caused by this window of data, the port can be deter- 
mined. 

The technique was not tested in practice. 
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7 Protection 



bility. 



To be fully protected against side channel information 
leakage described in this paper, the protocol would need 
to ensure that not authenticated segments are never an- 
swered. If it was the case, the only information that 
would leak to an off-path attacker, would be that the 
segment was not authenticated. Providing authentication 
mechanism is strong enough to make probability of gen- 
erating acceptable request negligible, the attacker learns 
nothing through the side channel that couldn't be figured 
out without mounting the attack. The TCP Authentica- 
tion Option [14] provides exactly such mechanism, but 
the option is not widely used. 

In case of sequence numbers based authentication, it 
can be difficult to ensure in a backward compatible way 
that the protocol never responds to rejected segments. 
Sequence numbers have double purpose. They were in- 
tended primary for detecting duplicates, lost and out of 
order segments. The use of sequence numbers as a pro- 
tection mechanism against an adversary was emergent, 
not even mentioned in the original specification. If Net- 
filter filtered SYN-ACK segments addressed to an estab- 
lished connection and dropped ACK segments with in- 
valid sequence numbers, the attack against a system pro- 
tected by Netfilter would be probably impossible. But 
such stricter filtering rules require very careful analysis 
to prevent hanged connections in corner cases. 

Throttling responses to rejected segments should 
be sufficient to make the information leakage non- 
exploitable in practice. Throttling mechanism for ACKs 
generated in response to in-window RSTs and in-window 
SYN-ACKs was proposed in [3]. To be effective, the 
mechanism would need to throttle also ACKs generated 
in response to other rejected segments. 

The attack is the easiest if the attacker shares an edge 
router with the victim. The first few hops are also the 
best place to reliably filter spoofed IP packets. Network 
that is configured to drop such traffic is protected at least 
against a local attacker. 

Queueing policy that better isolates traffic coming 
from different users could make the attack more difficult 
to execute. A privacy protecting scheduling policy was 
studied in [15]. The authors were able to significantly 
reduce the correlation between traffic patterns of users 
sharing a routing queue without introducing prohibitive 
performance degradation. The designed policy reduced 
the leakage of information regarding the traffic pattern 
of a user, but the traffic load of a user was still leaking 
through the increased packet processing time. To execute 
the attack described in this paper, it is enough to detect 
increased traffic load, knowing the exact traffic pattern is 
not necessary. Further research is needed to assess the 
effect of different queuing policies on the attack applica- 



8 Summary 

The paper demonstrated how changes in processing time 
of packets that traverse a shared queue can reveal if a host 
responded to spoofed traffic. It was shown that in case of 
the TCP protocol, being able to determine if a system re- 
sponded to spoofed segments is sufficient to compromise 
the session, direct interception of the TCP traffic is not 
required. Two different TCP implementations with dif- 
ferent processing rules were examined. Both implemen- 
tations responded to partially incorrect TCP segments, 
allowing the attacker to determine values of secret fields 
in separate steps. Substantial part of the work was dedi- 
cated to experiments to determine if the attack is practical 
in real-life scenario and to provide estimates of resources 
needed. The paper concluded with the discussion of pos- 
sible attack prevention mechanisms. 

The work did not try to determine the practical limits 
of the technique. There is a lot of room for further exper- 
iments in scenarios more adverse for the attacker (lower 
bandwidth between the attacker and the victim, busy bot- 
tleneck shared between many users, different queuing 
policies). Provided proof of concept can be used as a 
starting point for such experiments. The paper also did 
not attempt to provide a detailed survey of applicability 
of the technique against popular TCP implementations. 
Finally, the paper concentrated on compromising TCP 
session, but the presented technique can be applicable in 
other scenarios. 
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